refactor!: proof_of_sql_parser::intermediate_ast::UnaryOp
with sqlparser::ast::UnaryOp
in the proof-of-sql crate
#363
+29
−8
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please be sure to look over the pull request guidelines here: https://github.com/spaceandtimelabs/sxt-proof-of-sql/blob/main/CONTRIBUTING.md#submit-pr.
Please go through the following checklist
!
is used if and only if at least one breaking change has been introduced.source scripts/run_ci_checks.sh
.Rationale for this change
This PR addresses the need to replace the
proof_of_sql_parser::intermediate_ast::UnaryOp
with thesqlparser::ast::UnaryOp
in theproof-of-sql
crate as part of a larger transition toward integrating thesqlparser
.This change is a subtask of issue #235, with the main goal of streamlining the repository by switching to the
sqlparser
crate and gradually replacing intermediary constructs likeproof_of_sql_parser::intermediate_ast
withsqlparser::ast
.What changes are included in this PR?
proof_of_sql_parser::intermediate_ast::UnaryOp
have been replaced withsqlparser::ast::UnaryOp
UnaryOp
has been updated to maintain the original functionality, ensuring no changes to the logic or behavior.UnaryOp
variants fromsqlparser
have been appropriately handled using existing error handling mechanisms (i.e., theUnsupported
variant inExpressionEvaluationError
).Are these changes tested?
Yes
Part of #235